1. Field of the Invention
This invention relates to the management of telephone systems and in particular to the efficient integration of components of a telephone system for ease of use.
2. Description of Prior Art
As technology continues to march forward year after year, the telecommunications professional is faced with an ever increasingly complex task of dealing with these systems. In the early days (circa 1982-85), a corporation""s telecommunications infrastructure typically consisted of only a single phone system using a single Public Broadcast Exchange (PBX). When a new employee came aboard, maintenance on this system was relatively simplexe2x80x94a few commands was all that was required to add a new phone.
However, as corporations grew, so did their phone systems. Soon, companies had multiple systems scattered among several sites. When an employee moved from one site to another more commands were needed to accomplish this taskxe2x80x94a xe2x80x9cdeletexe2x80x9d on the old system and an xe2x80x9caddxe2x80x9d on the new system.
Telecommunication professionals invented new ways in dealing with these changes. By using change requisition forms and control sheets, the work could be managed and processed in bulkxe2x80x94all manually. This technique workedxe2x80x94for a while.
For years, the only way to get reports on a corporation""s phone activity was to wait for the bill from the phone company. However, soon the owners of these systems realized they too could track phone activity by using special data ports in the PBX. These ports became known as Station Message Detail Records or SMDR. The concept was simplexe2x80x94every time a phone call was completed, the PBX would transmit a single SMDR data packet. These data packets could be collected, stored on a computer, and detailed reports could be generated. A new system known as Call Accounting was introduced to meet this requirement.
However, Call Accounting systems also required their own data management. When a new employee came aboard, the telecommunications professional had to add a data record into the Phone System and into the Call Accounting system as well. When an employee moved, multiple records and multiple systems needed updating. But technology did not stop there. Soon corporations began replacing individual telephone answering devices with more economical Voice Mail Systems (VMS). These systems could literally replace thousands of individual answering devices with a single machine. However, these systems needed data management as well.
With the introduction of Computer-Based Phone Directories, Human Resource Systems, Credit Card/Authorization Code Systems, Emergency 911 Systems, Service Billing Systems, Network Access Devices, and many others, the telecommunications professional was soon faced with updating as many as 10 (or more) separate systems with the exact same information. Even with forms and procedures, this task was difficult at best and very error prone. Obviously, a better method was needed. The professional had to wait until around the early 90""s before solutions were attempted to address this problem. The first attempt at solving this problem was known as product integration. The concept was simple, a telecommunications vendor would produce a product that would combine all of the needed features into a single package. By having all of the telecommunication systems in a single platform, software could be engineered to share a single database. This would allow a single data management screen to be presented to the telecommunication professional. From this screen, all products could be updated at once. Soon, products began appearing on the market that were Call Accounting+ Voice Mail+ Phone Directory (or the like) all in one software package. North Coast Logic produced two generations of such packages (VSX and ARENIX). These packages worked in many environments and are still in use today.
However, they didn""t work in all situations. One problem was many corporations wanted multi-vendor solutions. The telecommunications professional did not want to be dependent on single vendor for the entire communications infrastructure. They wanted to shop and get the best value. They also soon realized that a single vendor could not be an expert in every industry. Another problem was that these integrated products typically consisted of a single hardware platform. All applications ran on a single machine. If that machine failed, the entire infrastructure was brought down. Even though many vendors tried to compensate for this by using highly reliable (and redundant) equipment, the solution still fell short of relieving the mounting workload on the professional.
The problem with a single database design became evident by the database technology itself. No single database technology fills every application requirement. Each vendor makes database technology decisions based on their unique system framework. For example, a Call Accounting system may be able to use any off the shelf Database Management System (DBMS), but a Voice Mail System needs a specialized data streaming system that is able to store and retrieve recorded voice data at 4-8 kb per second. A Phone System database is usually completely stored in memory and made up of a series of jump tables organized in a tree-like fashion. This allows the system to traverse the database as each digit is dialed. No off the shelf database product would fit all of these unique requirements.
In addition to the problems described above, an even worse issue exists with these early integrated systems. In a typical telecommunications environment, each of these systems have their own data entry terminal. This means that if the telecommunications professional does not use the integrated data management screen to do updates, the various databases in each system will become out-of-sync with each other. This is known as the multiple-entry problem.
For example, suppose that the telecommunications professional updates the phone system via its own data entry terminal, but updates the Call Accounting and Phone Directory via the integrated data management screen. In this scenario, it is possible that the changes made directly to the PBX may be lost or be left different than those in the integrated product. The two databases are out-of-sync.
Although it is tempting to mandate that all data entry is done via the integrated screen, in practice this is seldom the case. In many situations, work is required to be performed on a specific system and may require the use of a special field not accessible via the integrated screen. Even if all features could be moved to the integrated data management screen, the user interface would be so unwieldy that no user could navigate it.
The system of the present invention is an integrated suite of system control and application-software modules used to manage one or more telephone systems. In addition to controlling commonly used PBX telephone systems, the invention controls adjunct systems such as voice mail systems and 911 emergency systems. The system of the invention ties its application modules and system control modules together through a single point of entry and a synchronized database. Information entered through one module is automatically accessible by all other modules.
Repeated data entry and multiple system management are eliminated for client applications such as call accounting, cabling, assets, work orders, trouble tickets, traffic analysis, authorization codes, bill reconciliation, billing and13 other applications. The system ties its modules together across a LAN or operates as a stand-alone system. Operators can use networked computers for number lookup on its interactive directory or for information distribution via its message center.
The modular design of the telemanagement system of the present invention allows modules to be easily added to suit a company""s growing needs. As technology advances, the system provides seamless integration between the PBX, the voice mail, and each existing, or future module.
Second, the system easily synchronizes several databases, allowing them to operate as one. It is impractical to manage multiple applications and devices with a single database. Technicians are comfortable with PBX and voice mail programming. Requiring them to relearn system programming through a new interface can jeopardize system stability. The system of the present invention reaches out to the PBX and the voice mail databases and adjusts them by reading from or writing to them. Users can synchronize records one at a time or all together. A reconciliation feature compares databases and makes changes where deemed appropriate.
The client software program modules may be divided into five categories:
1. Interface Management. This is the basic minimum system with a system manager and call accounting. A graphical single user interface is included that incorporates all graphical user interfaces of all program modules of the invention. The manager controls the collection and costing of incoming and outgoing telephone calls, and creates predefined and user created reports on the telephone calls. The reports may be printed on a number of printers which may be connected to the network or locally to individual computers.
2. System Management. Automate common telemanagement programming and maintenance tasks, and track and schedule equipment requests and repairs;
3. Facilities Management. These modules track telephone cables, track telephony assets, bill for calls, services, and equipment and perform bill reconciliation to compare incurred charges from service provider;
4. User Management. These modules manually receive, forward and record telephone calls, and provide an interactive directory e.g., internal enhanced yellow pages; and
5. Network Management. These modules authorize calls and to analyze traffic.
The server programs include a program for collecting and costing calls from the PBX and an interprocess communication program. Also included are system control modules to control Maintenance Administration Terminal functions of PBXs, setup and monitor voice mail systems, and control 911 emergency system databases.
The system of the present invention may be embodied in a single computer readable medium such as a floppy disk or CD ROM for stand alone use. Alternatively, server programs are provided on one computer readable medium and the client program and modules are provided on a second computer readable medium.
In the stand alone system the system of the present invention is embodied in an article of manufacture comprising computer readable program code means for creating and managing a master database for maintaining a copy of information contained in each PBX and adjunct system database; means for collecting SMDR data from the PBX switch and converting the data to CDR data based on the information in the master database; means for generating a plurality of call accounting reports based on the CDR data and the information in the master database; means for generating a plurality of call accounting queries based on the CDR data and the information in the database; means for providing a single user interface for entering data into the master database and the PBX and adjunct system databases, and for requesting call accounting reports and queries; means for processing communications between the master database, the PBX database, the adjunct system database through the single user interface; and means for synchronizing the entry of the same data into each of the master database and the PBX and adjunct system databases through the single user interface.
The program code means further includes means for managing PBX switch Maintenance and Administration Terminal functions from the single user interface; and means for managing voice mail system functions from the single user interface. The computer readable program code means further includes one or more computer readable program code modules, each of the modules providing a client application telemanagement function.
In a client/server system, the system of the present invention is embodied in an article of manufacture wherein the server computer readable program code comprises means for creating and managing a master database for maintaining a copy of information contained in the PBX and adjunct system databases; means for collecting SMDR data from the PBX switch and converting the data to CDR data based on the information in the master database; and means for processing communications between the master database, the PBX database, the adjunct system database and the client computer readable program code means.
The client computer readable program code comprises means for providing a single user interface for entering data into the master database and the PBX and adjunct system databases, and for requesting call accounting reports and queries; means for generating a plurality of call accounting reports based on the CDR data and the information in the master database; means for generating a plurality of call accounting queries based on the CDR data and the information in the master database; and means for synchronizing the entry of the same data into each of the master database and the PBX and adjunct system databases through the single user interface.
In addition, the collection program is embodied in a program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform method steps for converting SMDR data collected from a PBX switch to CDR data. The method steps include:
checking if the format of the SMDR data is correct;
checking if the PBX switch is a listed switch;
checking for a valid billing range, switch record, facility and cost definition;
checking the number of digits of the SMDR data;
checking whether to store the SMDR data;
costing stored SMDR data for creating CDR data:
checking for a user name for the SMDR data; and
creating a CDR data file matching the CDR data to the user name.
The collection program also includes a program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform method steps for converting a record of a phone call collected from a PBX switch to 10 digits. The method steps include:
detecting and stripping access codes;
detecting and tagging x11 calls;
detecting and stripping common carrier codes;
detecting and tagging international calls;
detecting and tagging operator calls;
detecting long distance calls and converting the calls to 10 digits; and
detecting local calls and converting the calls to 10 digits.